為什麼我們需要 Dify？

在 Day 5 中，我們成功打造了結構化的「情境生成 Prompt」，並驗證能透過 JSON 輸出穩定的角色設定與開場白。

但隨之而來的是工程上的現實考驗：

• 如果每次呼叫 LLM 都要在後端自己手寫 API 請求、處理重試（Retry）、維護對話歷史（Context Memory），開發成本極高。
• 當未來要加入「英文文法錯誤分析」、「母語者表達推薦」甚至是「RAG 檢索」時，如果所有邏輯全塞在後端程式碼裡，不僅難以除錯，也缺乏視覺化調整的彈性。

這就是 Dify 進場的時機。

Dify 是一個開源的 LLM 應用開發平台。它將提示工程（Prompt Engineering）、上下文記憶管理、RAG 檢索與工具調用，抽象化成視覺化的節點（Nodes）。我們可以像拼積木一樣，把複雜的 AI 邏輯組裝成穩定的工作流。

核心觀念辨析：Workflow vs. Chatflow

進入 Dify 後，最常面臨的第一個抉擇是：該選 Workflow 還是 Chatflow？這兩種架構在我們的「AI 情境英文教練」專題中各有不可替代的定位。

1. Workflow（工作流：單次任務導向）

• 運作機制：具有明確的「開始節點（Start）」與「結束節點（End）」。接收特定輸入變數後，依序經過多個處理節點，最後輸出固定結果。
• 特性：無對話記憶（Stateless），每次執行都是獨立的計算。
• 專題應用場景：
  • Day 5 的「情境生成」（輸入場景 ➔ 輸出 JSON 角色與開場）。
  • 未來的「個人化學習報告生成」（輸入整輪對話紀錄 ➔ 分析整理出學習摘要）。

2. Chatflow（對話流：多輪互動導向）

• 運作機制：在 Workflow 的基礎上，原生整合了對話記憶（Chat Context / Memory）。
• 特性：有狀態（Stateful），系統會自動在後台記錄使用者的上一句、AI 的上一句，並在每次請求時組裝上下文。
• 專題應用場景：
  • 使用者與店員或面試官進行「即時英文 Role-Play 對話」。

兩者比較一覽表

Dify 必學的核心節點（Node）拆解

在 Dify 的畫布上，有幾個節點是建構本專題不可或缺的基石：

1. Start / End 節點（輸入與輸出）

• Start 節點：定義工作流接收的外部參數。例如設定 user_scenario（使用者情境）與 target_level（英文級別）。
• End 節點：指定工作流最終回傳給後端或前端的變數，通常用來輸出結構化字串或解析後的 JSON 物件。

2. LLM 節點（智能中樞）

• 負責實際呼叫底層模型（如 GPT-4o、Claude 3.5 Sonnet 或 Gemini 1.5 Pro）。
• 在這裡可以直接填入我們在 Day 5 設計好的 Prompt，並使用 {{#start.user_scenario#}} 語法引用上游傳來的變數。
• 可直觀調整 Temperature（溫度參數）：需要標準 JSON 時調低（如 0.2），需要豐富情境發想時調高（如 0.7）。

3. Code 節點（資料清洗與結構轉換）

• 允許在工作流中運行輕量級的 Python 或 JavaScript 程式碼。
• 關鍵用途：當 LLM 輸出的 JSON 字串偶爾夾帶 Markdown 標記（如 json ... ）時，透過 Code 節點執行正規表達式或 json.loads()，能確保下游節點拿到乾淨的資料物件。

4. Knowledge Retrieval 節點（知識檢索 / RAG）

• 連接 Dify 內建的向量資料庫（Vector Store）。
• 這是專題後續階段（第四階段）要導入的功能：讓 AI 在糾正英文時，主動檢索「母語者常見道地片語庫」，避免模型憑空捏造俚語。

專題實踐：情境生成器的 Dify 節點鏈路構想

把 Day 5 的成果搬到 Dify 上，整體鏈路設計如下：

Start 節點（輸入情境參數） ➔ LLM 節點（Day 5 Prompt） ➔ Code 節點（驗證/清洗 JSON） ➔ End 節點（輸出結構化資料）

1. Start 節點：定義兩個欄位：
   • user_scenario（Text，必填）
   • target_level（Select 下拉選單：A2 / B1 / B2，預設 B1）
2. LLM 節點：載入 Day 5 的 Prompt 模板，溫度設為 0.3，綁定輸入變數。
3. Code 節點：驗證輸出的字串是否符合預期的四個核心欄位（scenario_summary、dialogue_kickoff、recommended_expressions、common_pitfalls）。
4. End 節點：將標準 JSON 物件輸出，供後續發布為 Webhook 或 API。

本日小結與明日預告

Day 6 梳理了 Dify 的核心運作機制。透過區分 Workflow 與 Chatflow，我們為專題理清了清晰的架構：

• 前置設定與結尾報告交給單次、無狀態、要求格式精準的 Workflow；
• 中間的 Role-Play 英文對話則交給具備上下文記憶的 Chatflow。

明天（Day 7），我將正式動手在 Dify 畫布上建立這套情境生成 Workflow，實際串起 Start 到 End 節點，並進行第一次完整的端到端（End-to-End）視覺化測試！